Multicast technology makes it possible to send data from a single source to many recipients through a data network, without having to set up unicast communication, i.e. one-to-one individual communication between the source and each of the recipients. To that end the source sends data, in data packet form, to a single address associated to a multicast group to which the equipment interested in being recipients of the data sending can subscribe. This address, referred to as a multicast address or also as a multicast group address, is an IP (Internet Protocol) address chosen within a range that is reserved for multicast applications. The data packets which have been sent by the source to the multicast address are then replicated in the different network routers so that they can reach the recipients that have joined the multicast group.
The recipients which receive data in a multicast group are usually equipment connected to the data network by means of a proxy or a router. Hereinafter, the common term host will be used to refer to the recipient equipment. A host can be, for example, a computer or a set-top box (digital signal decoder) connected to a television set.
When a host wants to receive the information sent by one or several sources of a multicast group, it sends to the closest router, or to an intermediate proxy, a subscription message to subscribe to the group so that the router transmits to it the data arriving through the data network and which has been sent by the sources of the multicast group. Likewise, when a host wishes to stop receiving data sending in the multicast group, it sends to the router or to the proxy an unsubscribe message to stop receiving them.
The messages exchanged between a host and the closest router to manage membership to a multicast group use the IGMP protocol (Internet Group Management Protocol) or the MLD (Multicast Listener Discovery) protocol, according to whether or not the router works with version 4 (IPv4) or version 6 (IPv6) of the IP protocol (Internet Protocol), respectively.
When there is a proxy between the host and the router, the proxy also uses the IGMP/MLD protocols to exchange with the host, the closest router or other intermediate proxy, the multicast group membership messages. In these cases, the proxy can receive from different hosts requests to subscribe to or to unsubscribe from a multicast group, and it assembles them to thus reduce IGMP/MLD message traffic it sends to the router. Hereinafter, the generic term IGMP proxy will be used to designate a proxy using the IGMP/MLD protocols.
In addition, routers exchange messages with one another for the purpose of defining the routing which allows efficiently routing the data from the sources to the hosts that have subscribed to a multicast group. To that end, the routers use specific protocols, including the very well known PIM-SM (Protocol Independent Multicast-Sparse Mode).
In summary, the routers receive from the hosts, in the form of IGMP/MLD messages, information specifying which multicast groups they want to receive traffic from, and they communicate with other routers, for example by means of the PIM-SM protocol, for the purpose of setting up a routing which takes the traffic requested by the hosts to such hosts.
All the mentioned protocols are defined and documented by the Internet Engineering Task Force (IETF).
The IGMP protocol version currently being used is IGMPv3, which is described in the RFC 3376 specifications published on line by the IETF (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments 3376, October 2002.
With regard to the MLD protocol, the version currently being used is MLDv2, which is described in the RFC 3810 specifications published on line by the IETF (R. Vida et al., Engineering Task Force, Network Working Group, Request for Comments 3810, June 2004.
The operation of an IGMP proxy is described in the RFC 4605 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, August 2006).
The PIM-SM protocol used for the communication between routers is described in the RFC 4601 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, August 2006).
Multicast technology was initially implemented primarily to be applied to the many-to-many communication model, known as ASM (Any Source Multicast), in which many users communicate with one another and any of them can send data and also receive data from everyone else. A typical ASM application is multiparty calling via Internet.
Multicast technology was then implemented to be applied to the one-to-many communication model known as SSM (Source Specific Multicast), in which a single source sends data for many recipients. Radio and television via Internet are SSM applications. This is why SSM is currently very interesting.
In earlier IGMP protocol versions, a host could not choose the data sending sources it did not want to subscribe to within a multicast group, rather the host could only subscribe to or unsubscribe from the group for all the sources. The messages a host sent to a router were very simple: Join (G) to receive traffic from the multicast group G and Leave (G) to stop receiving it. Therefore, earlier IGMP protocol versions did not allow SSM.
The possibility that the hosts could choose the sources within a multicast group was introduced in the IGMPv3 version of the IGMP protocol to allow SSM. To that end, a host can send IGMP messages containing data blocks referred to as Group Record in which the host defines the sources from which traffic is to be received for each multicast group. These Group Record data blocks in an IGMP message can be of several types:                An INCLUDE type Group Record data block containing information on source IP addresses from which the host wishes to receive data sending. According to the terminology of the RFC 3376 specifications, the sources chosen by means of an IGMP message containing an INCLUDE type Group Record are referred to as INCLUDE sources.        An EXCLUDE type Group Record data block, containing information on source IP addresses from which the host does not wish to receive data sending. In this case, it is interpreted that the host wishes to receive data sent by all the sources of the multicast group except the sources indicated as excluded in the message. According to the terminology of the RFC 3376 specifications, the excluded sources by means of an IGMP message containing an EXCLUDE type Group Record are referred to as EXCLUDE sources.        
For clarity's sake, the term INCLUDE message will be used hereinafter to designate an IGMP or MLD type message containing an INCLUDE type record or Group Record, and the term EXCLUDE message will be used hereinafter to designate an IGMP or MLD type message containing an EXCLUDE type record or Group Record.
Each network interface and multicast group has a state record storing the information on the interface and group and the state record contains a field referred to as filter-mode which can only be of the INCLUDE type, containing only INCLUDE sources, or of the EXCLUDE type, containing only EXCLUDE sources. The rules that are transcribed below are applied when the network interface record must result from the combination of different records:                Rule 1. If any of the data sources of a group G1 is EXCLUDE, then the network interface will have an EXCLUDE filter-mode for the group G1 and the source list of the network interface is the intersection of the EXCLUDE source lists minus the sources of the INCLUDE lists.        Rule 2. If all the sources are INCLUDE type sources, then the network interface will have an INCLUDE filter-mode for the group G1 and the source list is the union of all the INCLUDE sources.        
These rules are applied in a network interface of equipment operating as an IGMP proxy and receiving INCLUDE messages or EXCLUDE messages from different hosts or from different IGMP proxies located downstream from the network interface (i.e. in the direction going from the router to the hosts). These same rules are also applied in a network interface of equipment, such as a personal computer for example, provided with several sockets receiving different INCLUDE source or EXCLUDE source requests from different applications.
Channel (S, G) is used hereinafter, and according to the common nomenclature in SSM technology, to refer to the sending of source S of the multicast group G.
In the current state of the art, routers using the IGMPv3 protocol store only the minimum multicast traffic information that they must transmit. This minimum information consists of storing, for each network interface of the router and multicast group, a state reflecting if, for a specific channel (S,G) or multicast group (*,G) there is at least one host interested in receiving the multicast traffic.
In a multicast system operating with the IGMPv3 protocol, different hosts connected directly to a single network interface of a router through a multiaccess network, such as an Ethernet network for example, can send different IGMP messages with multicast traffic requests referring to a single multicast group. Each of these IGMP messages contains its own INCLUDE type or EXCLUDE type sources. The router receiving these IGMP messages has to decide which multicast traffic it must send for each network interface and for each multicast group such that it meets all the traffic requests it has received through the IGMP messages. This problem is solved in the IGMPv3 protocol as follows: when an IGMPv3 router, which is initially transmitting multicast traffic from specific sources of a multicast group G, receives a new IGMPv3 message referring to the group G, it continues transmitting all the traffic from the sources that it was transmitting plus the traffic from the new sources requested in the new IGMPv3 message. Furthermore, to prevent indefinitely transmitting traffic from sources which no host wishes to receive, in specific cases the IGMPv3 router sends a Source-And-Group Specific Query type message to the multicast address G that all the hosts which are receiving traffic from group G listen to find out if there are still hosts interested in continuing to receive the multicast traffic from specific sources.
This solution adopted in the IGMPv3 protocol is a solution to the problem of managing the different source requests that different hosts make for a single multicast group. However, as will be seen below in the detailed description of the embodiments of the invention, the solution has the drawback that the implementation thereof involves enormous technical complexity, and it further involves rather inefficient multicast traffic management.
Another problem with the IGMPv3 protocol is that a single host can send a high number of requests to the router and even collapse it. The router is not able to detect this situation and therefore is not able to prevent it.
As will be explained below in the detailed description of embodiments of the invention, another problem with the IGMPv3 protocol is that it also causes drawbacks for managing the interconnection between the IGMPv3 protocol (multicast communications between the router and the hosts) and the PIM-SM protocol (multicast communications between routers), specifically for managing the transmission between these two protocols of the information from the sources requested by the hosts.